Real time auction with end game

ABSTRACT

A real time auction system operates in a non real time mode, and an end game mode in which the users are placed in a forum. In both modes the users are capable of placing bids along with times when those bids should be executed. An agent treats the bids as secret until the time, and then at the time executes those bids.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of the U.S. Provisional ApplicationNo. 60/169,728 filed on Dec. 8, 1999 and U.S. application Ser. No.09/669,805, filed Sep. 26, 2000.

BACKGROUND

The present invention describes a new paradigm for conducting an auctionon a remote information server such as the Internet.

The Internet is an extremely powerful tool for conducting auctions.Literally millions of users can simultaneously take part in a singleauction. Auction sites such as E-bay have popularized the Internetauctions. Each of these auctions allows bidding between virtually everyperson who has access to the Internet.

The auctions often last over an extended period of time, e.g. over oneweek. Many of these auctions use agents which automatically handle thebidding. The bidder instructs the agent with information about thebidder's maximum desired bid. The agent will bid only up to that amount.Moreover, the agent does not immediately bid its maximum amount; it onlybids an amount when the price of the item rises to a level that forcesthe agent to bid in order to keep the high bid.

It has been found that the most serious and competitive bidding canoccur at the end of the auction. Conversely, bidding early in theauction tends to cause the product to sell for more money than it wouldhave sold for otherwise. Therefore, people often wait until the lastinstant, e.g. the last minutes or seconds of the auction, beforebidding.

Auction sites such as E-bay often have fixed times for the auctionending. The auction ends at that moment, even if bidding may be mostintense at that moment. If a bid is placed, but not received before theinstant of the auction end, the item will sell. Therefore, Internetdelays can cause a product to sell for less money than it otherwisewould have sold for.

SUMMARY

The present invention recognizes that the standard model of Internetauctions is actually flawed. Auctions should be carried out more like areal live auction. While live auctions are known in the Internet art, adifferent kind of live auction is described herein. This live auctionincludes certain refinements which improve it for use on the Internet.

This includes an identification system with each of a plurality ofbidders being identifiable.

Another aspect includes a combination of an on-line auction and off-lineauction, with the off-line auction forming effectively a display periodfor the merchandise during which the users can place bids, and theon-line auction forming a final bidding period for the goods duringwhich the goods are actually sold.

Another aspect is an agent for use in an online auction, in which notonly the amounts of the bids, but also the time when those amounts arerelease, are specified.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects will now be described in detail with respect tothe accompanying drawings, wherein:

FIG. 1 shows a block diagram of the hardware used by the bidding systemof the first embodiment;

FIG. 2 shows a flowchart of operation according to a first mode;

FIG. 3 shows a flowchart of the special “agent” used in this auctionsystem;

FIG. 4 shows a flowchart of operation of an end game;

FIG. 5 shows a diagram of the forum showing the multiple users

FIGS. 6A and 6B shows flowcharts of bidding;

FIGS. 7A and 7B show a quick bid embodiment; and

FIG. 8 shows an embodiment that may prevent last minute bidding.

DETAILED DESCRIPTION

FIG. 1 shows a basic structure of a first embodiment of the biddingsystem. The bidding is actually carried out within a virtual environmentcreated by the central “server” computer 100. The server may be morethan one computer, which operate to execute a program as describedherein.

Server 100 keeps track of all the bids, and produces the graphicalenvironment that is displayed on each of the remote terminals, whereonly three remote terminals: 110, 120 and 130; are shown. Literallyevery computer on the Internet could be included. Each of the remoteterminals preferably obtains a view that is partly the same as theothers, and partly different.

Server 100 runs the flowchart shown in FIG. 2. The main flowchart runsthe beginning part of the auction as a conventional Internet auction,shown generally as step 200. The item to be sold is displayed. It islisted in some kind of index, or under a category. This can be thoughtof as the advertising part. Using an analogy to a real auction, this isthe portion of the auction where the items can be viewed.

In a particularly preferred embodiment, the item is viewed in threedimensions. A picture of the item is shown. The picture of the item canbe a two-dimensional picture or a three-dimensional picture. If athree-dimensional picture is used, the system first displays atwo-dimensional “splash” of the image while the system is loading thethree-dimensional information. The three-dimensional information is thenused to enable viewing the item three-dimensionally. This can be doneusing the techniques described in our application entitled “Touch andFeel on the Internet”; Ser. No. 09/505,646.

In whatever form the item is displayed, this is the period during whichthe users can see and find the items of interest. As conventional, thisportion of the auction also accepts bids, e.g. via a bid agent. Aspecial bid agent can be used as described herein.

This bid form continues until some specified time period (x) beforeauction close, e.g. one hour prior to auction closing. Step 205 showsdetecting that predetermined time, shown as time T−X. The auction modechanges to a mode that indicates the higher energy and interestassociated with this portion of the auction. Step 210 shows calling the“end game”, which is the routine that runs this higher energy portion ofthe auction. This changes the auction mode to a more interactiveatmosphere.

At step 220, all of the people who have registered for the auction andindicated a desire to participate in the end game are sent a message.This message can be sent in a number of different ways. An e-mail can besent to each person on the list. Pager numbers can also be contacted toleave an alphanumeric page indicating the URL of the auction site. Thesetwo techniques are especially advantageous when the email or page issent to a cellular phone of a type that allows web browsing. The endgamecan be carried out on the cellular phone, by clicking on the URL that issent.

An automated agent can leave an audio message (voice mail) on a person'snormal telephone, indicating that the end game has started.

After an endgame has started, and while still in progress, a user canlog into the auction site. The user enters their name and password, asconventional. Upon entering their name and password, the user receivesan indication, e.g. via a pop up window with a prompt, that the end gamefor this auction is in progress. The pop up window can take themdirectly into the end game environment.

The special agent program used herein takes into account the realitiesof such a system. Bidding too early in the process can increase theprice for an item. Usually the prices in the early part of the auctionare kept moderate. The bidding often does not reach levels approximatingthe actual value until later in the auction.

The previously-used system automatically immediately made its bid basedon current bid amount. If two people gave instructions to their systems,those two people would automatically and immediately bid against eachother, until one was outbid. Consequently, users often do not placetheir bids early, to avoid starting such a bidding war.

The present application describes an agent which avoids this issue byusing a time profile. The agent allows setting bids, including maximumbids, and also setting times at which those maximum bids will beprovided.

Another operation describes a graphical user interface simplifying thatoperation.

The flowchart shown in FIG. 3 represents the agent manager (AGENT _(—)MG).

The user is first prompted for a maximum bid (MAX _(—) BID) at step 301.That maximum bid indicates the maximum that the agent will be authorizedto bid on the item. The agent will not bid any amount, however, untilauthorized to do so.

At step 310, a graphical representation of times and the maximum bid isdisplayed. The graph can initially show any desired profile of bid vs.time; here it shows the agent being authorized to bid the MAX _(—) BIDamount, immediately. This profile, however, can be changed. Step 320shows one technique in which the graph is edited. The user may, forexample, not allow any bids until the end game or allow a very moderatebid initially, and more bids in the end game. The profile as edited instep 320 shows no bids being authorized until a time y. That time y canbe determined with precision by resting the cursor over a time, andwaiting for a “screen tip” to be displayed. This graphical system can beeasily edited on many different platforms, e.g., a cellular phone thatallows web browsing.

At any point, instead of using the graphical user interface, the usercan select, e.g., right click, on a portion of the line, and use a textentry system. Step 330 shows a textual interface. The user can enterinformation, e.g.,

AT TIME t1,

ALLOW A MAXIMUM BID OF $x1, where the underlined information is entered.

However entered, the maximum bids and the times at which those maximumbids are allowed to be released, are stored at 340. This information isentered as a function of time, and hence can be stored as rules, forexample. A rule might read:

At time AUCTION _(—) END−0:30 (30 minutes before auction end), bid up to$10.

Option entry is carried out at step 350. Options can include:

Overriding previous bids during the end game. This can be important withan agent. If the agent has been instructed to bid up to $20, a later bidmay actually bid against the agent's previous bid, and force the agentup to its maximum. This system enables overriding previous bids placedwith the agent, in order to allow placing a higher bid. In someinstances, that overriding can be allowed, for example, only when ahigher bid is desired.

The ability to cancel a previously-entered rule.

Contact information to contact (at step 220) during the end game, and/ora request to enter the end game.

Authorization to automatically raise the bid for a reserve auction.

Other options are possible.

Each of these options are preferably written as rules that drive theautomated bidding program.

These rules written by the agent are kept secret until the time they areexecuted. Each of the rules includes an execute time. For example, forthe bid rules shown in step 330, each rule starts with at time t₁, do x.The present application contemplates placing multiple different bid/timecombinations in this way. For example, a first one could allow biddingup to $x1 at time t−1 hour; and a larger bid of up to $x2 at time t−½hour.

Prior to this time to execute, the main process running on the servercomputer cannot obtain the contents of the rule. Only the person whomade the rule can read the rule.

After the time t₁, the agent will bid up to the maximum amountspecified, not placing any bid until the time specified. However, sincethe time for the rule has passed, the server at that point knows certaininformation about the contents of the rule, and can use that informationas described herein.

Therefore, before the specified times, the rules are absolutely secret.No one except the bidder can find these rules. After the time, thecontents of the rules can be known to the server. The disclosureprovided herein describes how these bids allow faster bid processing,e.g. bid rejection and the like. Step 360 shows the agent generallycarrying out a time processing routine. At the specified time, each rulee.g. bid, is released.

For rules such as reserve handling, the time of release is the auctionend.

As described above, at the specified time, AUCTION _(—) END−X, the endgame routine is called, and the auction form changes. The end game isshown in FIG. 4. Step 400 detects a new bidder entering the end game. Asdescribed above, this can be done by the bidder signifying theirintention to enter the end game, or can be an automatically-created popup window when a previously-registered user logs in to the auction'swebsite. The flowchart shows verifying the identity of the new bidder atstep 402. Once the identity is verified, e.g., by username and password,the user is added to the participants list for the end game at step 404.

The endgame is carried out in a graphical forum. Each user is shown inthe forum, along with other users. The forum 500 is shown in FIG. 5.Once the new user has been added at step 404, the user is displayed inthe forum, with an icon indicating the user's status. The status caninclude credit rating or other information. The user is initiallydisplayed in the new bidder area 510. Step 406 illustrates displayingthe new user in the new bidder area.

In this embodiment, the user signs in, and thereafter can place bidswithout entering their name/password. This is different from otheronline auction paradigms, in which each bid requires the user'sname/password. This is more difficult for the user, and also slows downthe operation. In this paradigm, a session key can be established afterlogin, so that the communication occurs over a secure channel.

The check ID step of step 402 can be user verification by any means. Onesuch verification is specific to use with a web-browsing cellulartelephone. The caller ID of the calling telephone can be established.This establishes the user's identification automatically.

One feature of this real time auction is that the bidders must receiveinformation that is frequently updated. Typical web browsers, however,do not automatically update the information that they display.Accordingly, the present application uses automatic information updateto provide up to date information to the bidders.

This automatic information update can be done in different ways. One wayis to send an update command to the browser at specified intervals. Thisupdate command causes the browser to request a refresh, thereby loadingthe new and updated forum scene.

In another aspect, certain parts of the image that is displayed by theweb browser to represent the forum are defined as being streaming video.Streaming video is well known in the art, and displays a continuousstream of video to the user. A standard streaming video stream can beused.

Another option defines a special object within the web browserenvironment. This object is effectively stop motion video. At times theobject can be changing. When unchanged, the object remains the same.When the object receives information, it changes, without a need to“refresh”.

In any case, assuming that the standard web browser is used, a commandis sent to the web browser at step 408, requesting at least the newbidder's web browser to refresh. The new bidder sees himself added tothe new bidder section 510. Others might not see this addition untilsome other action causes them to refresh. However, a new bidder beingadded is not necessarily important to all bidders.

The add to participants list at step 404 includes assigning an agent tothe participant at 405, if necessary. The participant may already havean agent assigned from previous participation in the auction during thedisplay mode 200. If so, the user retains that agent. If not, a newagent instance is defined, e.g. by auction number and agent number. Theagent is assigned one-to-one with the user so that the user has his ownagent. As described above, that agent can keep secrets during thebidding process, even though that agent may be running within the sameserver that runs many of the other agents.

Also, after the ID is verified at 402, the user name is displayed alongwith the results of the id check. For example, the system may operate arating system for users. This rating system may include a credit ratingof the user, for instance a maximum bid that the user is authorized tomake.

Another rating is based on the user having entered a guarantee of bid.For example, the user may use a credit card as part of the bid/bidprofile process. When the bid is accepted and the auction is ended, thatcredit card is automatically charged for the bid amount.

Another option forces the user to post a bond, and can charge theauction against that bond in case the bid is not satisfied.

Yet another possibility is that other participants rate the oneparticipant, and provide a rating scheme that depends on the numberpositive and negative comments. This is similar to the rating schemeused by E-bay™. According to all of these systems, the user's name asdisplayed at step 406 may include an indication of the users rating.

Therefore, the user may be displayed as:

JOE BLOW;

RATING A;

BOND POSTED

until the amount of the bid reaches the amount of the posted bond. Afterthe bid exceeds the posted bond, the display can say:

JOE BLOW;

RATING A;

BOND AMOUNT EXCEEDED

If a credit card is used, the display can say

CREDIT CARD ON FILE.

Another option displays information about the user in color based on therating. A green rating means that the user has a good credit rating. Ablue rating means a guaranteed bid. A red rating may mean that thecredit line is exceeded.

At step 420, a new bid is detected. Step 422 obtains the amount of thenew bid. At step 424, the bidder who placed the bid is moved to the“current bids” area 520. The AGENT _(—) WIN routine (described hereinwith reference to FIGS. 6A and 6B) is called at step 426. The currentbid amount is fed to this routine to determine if the current bid is awinner, and to take action based thereon.

The agent win routine can be done in one of two different ways shown inFIGS. 6A and 6B. These depend on the way that the system handles bids.

A number of variables are defined associated with the bidding process.

NEW _(—) BID is the amount of a newly-placed bid.

MIN _(—) BID is the minimum amount that needs to be bid to place a bid.This value is related to the current bid (CURR _(—) BID), and thebidding increment (BID _(—) INC).

WIN _(—) BID is the amount that is necessary to win the current auction(until outbid). This value may or may not be known to the local agent.

The local agent is partially resident on the client computer, e.g., asan applet running on the client computer. This is done to allow fasterreaction to bids. Preferably at least a part of the agent, runs on theusers terminal. This part of agent includes certain numbers whichfacilitate accepting or rejecting bids. For example, the applet iscontinually updated with minimum bid amounts and, to the extentpossible, with winning bid amounts. During the end game, when the userplaces a bid, the agent is able to accept or reject the bidsubstantially immediately. Then the agent can send a specified signal tothe mainframe computer that is actually moderating the bid. Thespecified signal can include an indication that an acceptable bid isfollowing. This can substantially speed the process, since an indicationof an acceptable bid can be quickly sent and received by the clientcomputer.

FIG. 6A is executed when the maximum among the released bids are knownto all agent applets. The new bid is detected at step 420. All agentsare continually updated with MIN _(—) BID, WIN _(—) BID, CURRENT _(—)BID at step 610. At step 612, all the values are updated to allparticipants.

At step 614, the current bid (CURR _(—) BID) is compared with the valueof the winning bid (WIN _(—) BID). If the current bid is found to beless than the winning bid at 614, a message is returned to the userplacing the bid, indicating “outbid” at 620. The current bid is also setto the value of new bid at step 625, thereby increasing the new minimumbid (=CURR _(—) BID+BID _(—) INC).

These new variables are sent to the mainframe, and at steps 610/612 aresent to all agents. All agents therefore store the values from which itcan be immediately ascertained whether a locally-placed bid will win ornot.

If the new bid is greater than the winning bid at step 614, then the newbid becomes a winning bid at step 630. The current bid is set to thevalue of the winning bid at step 630. Note that the current bid is notset to the new bid, unless the new bid=the winning bid. Instead theagent manager is called as described below. At step 635, the new amountis displayed, and the bidder is moved to the top of the screen showingthe forum. The system also sends a global update, to update all users toindicate a new winning bid, and a new order of users. Thepreviously-winning bid is placed to the current bidder's area.

If the new bid is greater than the winning bid at 640, the agent manageris called at 645 to define the bids to be released as a function oftime.

FIG. 6B shows the alternative in which the winning bid variable is notknown globally to all agents. In this case, a new bid at 420 causes atest to be made at step 650 to determine if the current bid is greaterthan the minimum bid. If so, the minimum bid is posted to the agentholding the winning bid (AGENT _(—) WINBID) at step 655. AGENT _(—)WINBID determines, from its rules database, if it is authorized to placea bid that is high enough to win at the present time, at step 660. Ifso, then the current bid and minimum bid variables are appropriatelyincreased at step 665, and a notice of outbid is returned at 670. IfAGENT _(—) WINBID is not authorized to bid high enough, then the currentbid variable is set to the new value at step 675, and the processreturns an indication that the current bidder is now the winner. Allvariables are updated and sent to the mainframe for sending to allagents. The new bidder's agent also becomes the new AGENT _(—) WINBID at680. An update is posted globally at 685.

The difference between the two routines is the amount of informationheld locally. In the FIG. 6A routine, all agents have informationallowing them to determine locally whether any bid will win. The do notnecessarily display it, but they store the information. They can acceptor reject a bid locally.

In the FIG. 6B routine, the agents keep the bids secret. A bid can beposted to the agent holding the bids to determine if there is a winningbid. However, this takes longer to effect.

In both routines, the information is not available at all before thescheduled release time.

Returning to FIG. 4, step 430 illustrates that the time for auction isabout to expire. This may happen, for example, at the time of auctionexpiration or 2-10 minutes before. The first thing that happens at step432 is the global display of the word “going . . . ”. This is like areal auction, where the auctioneer warns the audience with this keyword. In this embodiment, the word may be displayed in a balloon comingfrom the auctioneer's or agent's mouth, as shown in the forum of FIG. 5.An update is sent at 434, so that all users will see this message.Alternatively, a new streaming video object is defined coming from theauctioneer's mouth so that the users see the “going” symbol. At thispoint, time is of the essence. Another paradigm becomes possible—thequick bid paradigm.

The quick bid is shown in FIGS. 7A and 7B. Again there are two modes forthe quick bid. In one mode, the agent knows all values. In this case,the agent can enable not only posting a quick bid, but also posting aquick winning bid. The agent in FIG. 5 shows the options for biddingwhen they are available. For instance, the quick bid 530 may bedisplayed as shown in FIG. 5, along with the quick winning bid 535.Passing the cursor over either value displays a “screen tip” that allowsthe user to view what the quick bid or quick winning bid amount will be.Since these values are known to the agent, they are stored in the localbrowser, and can be displayed quickly. The quick win bid may bedisplayed or not displayed, depending on rules, options andcircumstances of the auction. In one mode of operation, users areprovided with an incentive to share the winning bid with others. Forinstance, users may get a discount or other incentive to allow the quickbid to be known. Even if the quick bid quick win is known, it may onlybe allowed during the going, going, gone, during which time emotionsbecome higher.

The quick winning bid is also shown in FIG. 7B. In either case, when theuser clicks on the amount, they receive an instantaneous indication ofthe amount they have bid and a confirmation. By clicking yes, the bid isinstantly posted, hence stopping the going, going, gone process for atleast one minute as illustrated in step 440. After no further bids havebeen received, the moderator once again enunciates the going (step 432),beginning the end of the process. This can enable the quick bids asdescribed above.

In a normal auction, enunciating the first word “going” would be quicklyfollowed by another going. However, in this auction, the system mustallow time for users to get their bids in over the Internet. Hence,preferably at least thirty to sixty seconds elapse prior to the secondgoing at 445. After each instance of going, a global update is sent at450 or the going gone is displayed in streaming video. After additionaltime has elapsed at step 452, without additional bids being detected at454, the item is indicated as sold at 460.

Other embodiments are contemplated. For example, while the presentapplication describes doing this operation on the Internet, the sameoperation could be applied to any remote information server or network.The present technique refers to an auction, where the term auction isintended to include any forum in which bids can be placed, one bid whichis higher than the bid before it, excluding other bids which may belower. However, a “dutch auction” in which multiple highest biddersobtain the information, is also contemplated. The present applicationdescribes a few different ways of automatically updating the remoteservers. It should be understood that other techniques of automaticupdate of the remote servers are also possible. In addition, the presentapplication contemplates in some circumstances that some but not all ofthe remote servers will be updated.

Another aspect of this system is shown with reference to FIG. 8. Thepresent application has described what amounts to two oppositescenarios. A first scenario is based on the user's desire to place thebid as late in the auction as possible. By doing this, the bidder mayattempt to avoid a bidding war. In an eBay type auction with a fixedending time, this means trying to get the bid placed as close to thelast instant as possible. Of course, this exact same scenario may be badfor the seller. The seller may want to create a bidding war. Therefore,the above has described a system with a variable ending time to theauction; and/or an endgame.

The technique of waiting until the last instant to place the bid hasbeen titled “sniping”. Sniping may be advantageous for the buyer, sinceit avoids a bidding war, and may keep the price lower. However, thesniping bidder does place a higher bid at the last instant, henceincreasing the total amount of money that the seller receives. When antisniping techniques are used, a bidder may be motivated to place theirbid earlier in the auction. This may inevitably be in the seller's bestinterest. This embodiment discloses a way to make sniping less desirablefor the buyer.

The system as disclosed herein runs the flowchart shown in FIG. 8. Inthis flowchart, at 799, the seller selects anti sniping and specifiedoptions associated with the antisniping. At 800, normal auctioningprocedures are carried out. As part of the normal auctioning process,bidders' bids and identities are recorded. Those recorded bids andidentities may be used for the anti sniping techniques described herein.

One antisniping parameter entered at 799 is the time option. This timecorresponds to the time-to-auction-end. The system detects this time, an“endgame”, at 805. This may be the same endgame that as disclosed in theprevious embodiments, or may be a different endgame. Preferable timesfor the endgames may be between the last 2 minutes of the auction andthe last 2 hours of the auction, for example, although any time could beused.At 815, a user attempts to place a bid within this anti sniping endgame.The identity of the new bidder is compared against the list of previousbidders. That is, the identities of those users who attempt to place thebid during this time are compared against the latest bids accumulatedduring the normal bidding process at 800. If the new bidder is on thelist at 815, the bid is allowed to continue as normal at 820. If the newbidder is not on the list at 815, then an antisniping action is taken at825. The antisniping action at 825 can be many different optionsdescribed herein. In one embodiment, only bidders whose names are on thenormal bidding process list are allowed to place bids during this finalantisniping endgame. Therefore, bidders can not simply wait until thelast moments of the auction to place the bid.

In one embodiment, bidders can simply place of bid any time in theauction prior to the endgame to get their name on the list compiled at800. This would avoid the antisniping action at 825. One possibledisadvantage of this is that a bidder may be encouraged to place aminimum bid during the auction, to simply get on the bidders list.

Another embodiment at 801 compiles a list of only allows those bidderswho were previous-winning bidders as the anti sniping list. This forcesserious bidders to place a serious bid earlier in the auction to becomea winning bidder sometime earlier in the auction. In the embodimentusing operation 801, only early winning bidders become exempt from theanti sniping action 825.Yet another embodiment counts only winning bidders during a last timeperiod of the auction, e.g., during the last 2 hours of the auction onthe list that qualifies for exemption from anti sniping. Yet anotherembodiment counts no one on that list—all bidders placing bids at thelast minute are subject to anti sniping actions, whether they werewinning bidders previously or not. This is the furthest action inencouraging users to place their full-value bids early.

Another aspect of this system contemplates taking different anti snipingactions. This allows “sniping” bidders, however determined, to place abid. However, these bidders are considered on an unequal floating withother bidders. For example, many systems including eBay use an agent tomake sure that the bid which is placed stays at the lowest bid necessaryto win, even if a users maximum bid may be higher than this lowest bidneeded to win. One example of the system which may provide an unequalfooting for sniping bidders is to prevent sniping bidders from usingthis agent. If the winning bid is $500, for example, a user may placethe bid of $700. If the agent is used, and the lowest value needed towin the bid is $505, then the bid which is placed will be $505, even ifthe user's maximum bid is $700. However, with the unequal footingsystem, when the user places the bid, it will automatically be placed atthe maximum. Therefore, a user placing the bid at $700 willautomatically be bid at $700, even if that amount is not needed to winthe bid. This may produce advantages, since it seriously discouragesthese last minute bids. If they are made, the seller may secureadvantages from this, since the bids will be higher.

Other anti sniping actions are contemplated.

The use of the anti sniping agent, and it's options, may be set by theseller at 799. The seller may set these options when they are listingtheir product for sale.

All such modifications are intended to be encompassed within thefollowing claims, in which:

The invention claimed is:
 1. A method of conducting an auction over anetwork, comprising: receiving information from a server computer at alocal computer, which information enables the local computer to carryout a bidding function for an item, wherein said information includesinformation about a bid amount which will be necessary for a user at thelocal computer to overcome a bid by another on an auction item, wheresaid information is stored by said local computer and kept secret onsaid local computer and not shown to the user of said local computer;entering information for a new bid at the local computer; using thelocal computer for making a decision to accept or reject said bid from auser at the local computer based on said information about bid amount;and only if the new bid is accepted at said local computer, sendinginformation about the new bid from the local computer to the servercomputer, and otherwise not sending said new bid from the local computerto the server computer; wherein said new bid being accepted comprisessaid local computer comparing a local bid to said information about bidamount without sending information to the server computer, and saidlocal computer sending said information to said server computer onlywhen said local bid is higher than a number set forth in saidinformation about bid amount, and wherein said information about bidamount being hidden from said user.
 2. A method as in claim 1, whereinsaid information includes information about a highest bid amount whichwill be necessary for the user at the local computer to be a highestbidder, and wherein said accepting a bid comprises using the computerfor comparing a local bid to said highest bid amount, and sending saidinformation to said server computer only when said local bid is higherthan said highest bid amount.
 3. A method as in claim 1, furthercomprising automatically receiving information about a new highest bidamount in said local computer and updating said highest bid amount onsaid local computer without showing said highest bid amount to saiduser.